Social Debt Analytics for Improving the Management of Software Evolution Tasks

The success of software engineering projects is in a large part dependent on social and organization aspects of the development community. Indeed, it not only depends on the complexity of the product or the number of requirements to be implemented, but also on people, processes, and how they impact the technical side of software development. Social debt represents patterns across the organizational structure around a software system that may lead to additional unforeseen project costs. Condescending behavior, disgruntlement or rage quitting are just some examples of social issues that may occur among the developers of a software project. While the research community has recently investigated the underlying dynamics leading to the introduction of social debt (e.g., the so-called “community smells” which represent symptoms of the presence of social problems in a community), as well as how such debt can be payed off, there is still a noticeable lack of empirical evidence on how social debt impacts software maintenance and evolution. In this paper, we present our position on how social debt can impacts technical aspects of source code by presenting a road map toward a deeper understanding of such relationship. I. RESEARCH PROBLEM AND MOTIVATION Software engineering is clearly characterized by two main components, i.e., technical and social [39]. While the former is related to the processes aimed at producing sound technical products that meet the expected requirements, the latter has to do with the relationships involving organizations, developers, and stakeholders who are responsible for the definition of the technical product [12]. According to the Netherlands Knowledge and Innovation Agenda ICT 2016 2019, “software and system complexity is not solely of technological nature but also defined by people and processes”1. Indeed, the success of software engineering projects is strongly dependent on social and organization aspects of the development community [11]. In past and recent years the software evolution research community has actively focused on technical aspects of software projects, by (i) understanding the key factors making technical products easier to maintain [2], [4], [10], [29], [32], [44], [48] or (ii) devising techniques and tools to support developers during different evolutionary tasks [17], [25], [31], [36], [45]. For example, Cunningham [14] introduced the 1https://www.4tu.nl/nirict/en/Research/knowledge-and-innovation-agendaict-2016-2020.pdf metaphor of technical debt, which refers to practices performed by developers that lead to the introduction of bad design solutions that will turn in an additional cost during software maintenance and evolution. One noticeable symptom of technical debt is the presence of code smells [19], i.e., bad programming practices applied by developers that lead the source code to be less maintainable and more changeand fault-prone [30]. On the other hand, software communities have been the subject of several empirical investigations as well [5], [9], [15], [33], [40], [41]: in particular, they have mainly focused on how such communities evolve [21], [27], [28], [47], while they only partially considered the relationships between communityrelated information and software maintenance and evolution of technical products. Indeed, such studies especially targeted the so-called social debt, i.e., unforeseen project cost connected to a “suboptimal” development community (i.e., both in structure and behavior) [42], [43]. For instance, Tamburri et al. [41], [43] defined a set of community smells, a set of socio-technical characteristics (e.g., high formality) and patterns (e.g., recurrent condescending behavior, or rage-quitting), which may lead to the emergence of social debt. One of the typical community smells they found is the Organizational Silo Effect, which arises when a software community presents siloed areas that essentially do not communicate, except through one or two of their respective members: as a consequence, the development activities might be delayed due to lack of communication between developers. Besides the studies on social debt, a consistent number of empirical analyses have been carried out on the so-called socio-technical congruence [8], i.e., the alignment between coordination requirements extracted from technical dependencies among tasks and the actual coordination activities performed by the developers. While studies in this category had the intention to investigate the relationship between social and technical sides of software communities (e.g., studying how the collaboration among developers influence their productivity [16], [18]), we believe there is still a lack of evidence on their connection, i.e., how social-related issues occurring among the developers of a software project and indicated by the presence of social debt might impact the quality of both technical products and processes. In other words, it is still unclear whether factors like coordination issues, lack of communication, or structure of development community have an effect on the quality of source code (e.g., code smells [19]) or the quality of software processes (e.g., code review [2] and bug resolution [22] completion time). We believe that such relationship is of a paramount importance for enlarging the knowledge on how software systems evolve and how to properly support developers along with software evolution. While some exploratory studies in this direction have been conducted in the domain of requirements engineering for coordination by Cataldo et al. [8] and Kwan et al. [24], both these lines of inquiry and related research are still far from relating social and technical debt with the goal of comprehending their cocreation and evolution. In this paper, we present our position about the relationship between social and technical aspects of source code by describing our road map toward its proper management. II. ON THE RELATIONSHIP BETWEEN SOCIAL AND TECHNICAL DEBT The first envisioned step toward the exploration of the connection between social and technical debt is to assess whether such relationship actually exists and, as a consequence, what its strength is. In particular, we hypothesize that communityrelated issues can be the cause of introducing technical debt. To verify this hypothesis, we believe that future research effort should be devoted to design a number of empirical investigations aimed at characterizing the interaction between the two aspects, including but not limited to: 1) How social debt impact the presence of technical debt. As briefly explained in the previous section, community smells indicate frequent negative patterns over a software community organization that might result in additional project costs. We suppose that such project costs can be basically due to (i) pure social-related issues raising between developers and (ii) technical issues arising in the source code. While the causes behind additional costs due to the presence of social issues within communities [5], [9], [15], [34], an important challenge for the research community is that to assess the extent to which additional technical costs are due to social debt. Specifically, we believe that future research should focus on the relationship between social debt, e.g., measured in terms of community smells [41], and technical aspects such as (i) presence of code smells and (ii) introduction of defects. In the first case, a clear real-case scenario might involve the presence of sub-communities that do not communicate with each other (e.g., in presence of a Organizational Silo smell) that, as a consequence, are not able to come up with a correct way to modularize the different modules of the systems they are developing, thus possibly introducing architectural or code smells like Promiscuous Package or Blob [7], [19]. In the second case, it is reasonable to think that the presence of issues within a community might lead developers to misunderstand requirements implementation or design choices to apply, thus possibly introducing bugs. For instance, Kwan et al. [24] suggested that social debt not only impacts software build success, but also may contribute to worsen program comprehension. 2) How different software community types are affected by technical debt. As clearly visible looking at the modern software development practices, current systems heavily rely on open-source software (OSS) [13], [35]. Indeed, over the past years OSS has moved from an academic curiosity to a mainstream focus within software communities [13]. Despite their high popularity, open-source development communities rarely rely on governance insights from organizations research and/or tracking their organizational status using social networks analysis (SNA) [23], e.g., to evaluate the current salient social and organizational characteristics describing their community. Such a lack of structured information might lead to two undesirable consequences. On the one hand, the implosion of the community: for example, an increasing number of reflections and empirical evidence over abandonware [26], [37] or even failure of entire open-source forges indicates the need to understand and better support the organizational and social aspects of open-source communities [20], [38]. On the other hand, the introduction of specific technical debt based on the underlying community type of a software project: for instance, communities characterized by the presence of formal vs informal communications might suffer of different technical issues due to the different nature of developers’ interactions. Thus arises the need to support clients of OSS in the evaluation of the risks associated to the usage of such open-source code in their systems. Therefore, an important challenge is represented by a deeper analysis of (i) how to automatically identify the key characteristics of different community types so that they can be classified and (ii) to what extent different community types exhibit different technical debt such as code smells or bugs. To face the challenges described so far, a mixture of quantitative and qualitative analyses is required. Indeed, on the one the assessment of the relationship between social and technical debt needs to be performed by means of correlation, statistical, and predictive analyses. On the other hand, surveys or semi-structured interviews with developers might reveal additional insights on such a relationship, possibly explaining (i) the motivations behind it and (ii) effective ways to reorganize software communities to remove social debt. III. ON THE IMPACT OF SOCIAL DEBT ON TECHNICAL TASKS COMPLETION EFFORT Once we have assessed the actual relationship between social and technical debt of software systems, the subsequent step that we envision is to determine the impact of communityrelated aspects on different evolutionary tasks performed by developers during software maintenance. In particular, we believe that poor communication between developers increases the time needed to complete technical tasks such as code review, issue resolution, etc. This set of empirical investigations include: 1) How social debt impacts code review and bug resolution time. The modern assessment of software quality during maintenance and evolution is typically guided by modern code reviews [2]: In a typical code review, one or more developers dress the role of reviewers and verify that the proposed source code changes meet the quality requirements with respect to readability, maintainability, and the absence of defects, before being deployed into production. In this context, social issues occurring within the development community might influence this process in two different ways: (i) how source code is reviewed, i.e., the quality of a review, and (ii) the time needed to verify that the changes applied meet the requirements. Indeed, following the socio-technical argumentations proposed so far [8], [24], problems in the technical development may be a reflection of issues occurring at the community-level. At the same time, another critical software engineering process during maintenance and evolution is related to the way developers fix bugs [1]: on the one hand, we believe that the research community should focus on investigations aimed at understanding (i) how the presence of community-related issues impacts the ability to diagnose bugs and (ii) whether the time needed to resolve a bug is higher when the reviewer is involved in social debt. 2) How social debt impacts maintenance effort estimation models. Since its birth, software effort estimation has represented the Holy Grail of software engineering [6], since it supports project managers in the correct estimation of effort and costs needed to develop a software system. The problem is still more tricky when it comes to the maintenance and evolution: indeed, this phase is responsible for more than 80% of the total cost of software [3]. While some researchers proposed the use of product and process metrics for estimating the effort estimation of future maintenance tasks [46], following the conjectures reported previously in this section we believe that a promising challenge is to exploit social debt as additional factors to correctly estimate the costs of maintenance and evolution tasks. IV. IMPROVING SOFTWARE EVOLUTION TOOLS BY EXPLOITING SOCIAL DEBT Based on the results achieved from the studies described in Sections II and III, several software evolution tools might be improved by means of social debt analysis. For instance, it would be possible to study solutions aimed at (i) detecting social debt in software communities (e.g., by means of social network analysis techniques), (ii) prioritizing technical debt based on the co-occurrence of social debt, (iii) improving code review and bug resolution tools by exploiting social debt when recommending the developers that should perform such tasks, and (iv) improving maintenance effort estimation capabilities adding social debt information as additional predictors. The results of such line of research are intended to be useful for both managers, interested in solving potential social issues in a community, and developers, interested in estimating the effort—social and technical—required for maintaining the source code. Finally, the research might set a research agenda for socio-technical factors in software development.